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TFTP Multicast Option 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


The Trivial File Transfer Protocol [1] is a simple, lock-step, file 
transfer protocol which allows a client to get or put a file onto a 
remote host. 


This document describes a new TFTP option. This new option will allow 
the multiple clients to receive the same file concurrently through 
the use of Multicast packets. The TFTP Option Extension mechanism is 
described in [2]. 


Often when similar computers are booting remotely they will each 
download the same image file. By adding multicast into the TFTP 
option set, two or more computers can download a file 
concurrently, thus increasing network efficiency. 


This document assumes that the reader is familiar with the 
terminology and notation of both [1] and [2]. 


Multicast Option Specification 


The TFTP Read Request packet is modified to include the multicast 
option as follows: 


+-------- f—---—~ ~----4---4--* * --4---+4+----------- +—---+---+ 
| opce=1 | filename | 0 | mode | 0 | multicast | 0 | o | 
+-------- f—---—~ ~----4---4--* * --4---4+----------- +—---+---+ 

opc 
The opcode field contains a 1, for Read Requests, as defined 
Te Palsy te 
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filename 
The name of the file to be read, as defined in [1]. This isa 
NULL-terminated field. 


mode 
The mode of the file transfer: "netascii", "octet", or 
"mail", as defined in [1]. This is a NULL-terminated field. 
multicast 
Request for multicast transmission of the file option, 
"multicast" (case insensitive). This is a NULL-terminated 
field. The value for this option request is a string of zero 
length. 


If the server is willing to accept the multicast option, it 
sends an Option Acknowledgment (OACK) to the client including 
the multicast option, as defined in [2]. The OACK to the client 
will specify the multicast address and flag to indicate whether 
that client should send block acknowledgments (ACK). 


+------- peoe R RHE retea a A +—--+ 

| ope | multicast | 0 | addr, port, mc | 0 | 

+------- t----------- +---+------- aaa +---+ 
ope 


The opcode field contains the number 6, for Option 
Acknowledgment, as defined in [2]. 


multicast 
Acknowledges the multicast option. This is a NULL-terminated 
field. 


addr 
The addr field contains the multicast IP address. This field 
is terminated with a comma. 


port 
The port field contains the destination port of the multicast 
packets. The use of Registered Port number 1758 (tftp-mcast) 
is recommended. This field is terminated with a comma. 


mc 
This field will be either 0 or 1, to tell the client whether 
it is the master client, that is, it is responsible for 
sending ACKs to the server. This is NULL-terminated field. 
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Data Transfer 


After the OACK is received by the client it will send an ACK for 
packet zero, as in [2]. With the multicast option being accepted this 
ACK will indicate to the server that the client wants the first 
packet. In other words the ACKs may now be seen as a request for the 
n+1lth block of data. This enables each a client to request any block 
within the file that it may be missing. 


To manage the data transfer the server will maintain a list of 
clients. Typically the oldest client on the list, from here on 
referred to as the Master Client, will be responsible for sending 
ACKs. When the master client is finished, the server will send 
another OACK to the next oldest client, telling it to start sending 
ACKs. Upon receipt of this OACK the new master client will send an 
ACK for the block immediately before the first block required to 
complete its download. 


Any subsequent clients can start receiving blocks of a file during a 
transfer and then request any missing blocks when that client becomes 
the master client. When the current master client is finished, the 
server will notify the next client with an OACK making it the new 
master client. The new master client can start requesting missed 
packets. Each client must terminate the transfer by sending an 
acknowledgment of the last packet or by sending an error message to 
server. This termination can occur even if the client is not the 
master client. 


Any subsequent OACKs to a client may have an empty multicast address 
and port fields, since this information will already be held by that 
client. In the event a client fails to respond in a timely manner to 
a OACK enabling it as the master client, the server shall select the 
next oldest client to be the master client. The server shall 
reattempt to send a OACK to the non- responding client when the new 
master client is finished. The server may cease communication with a 
client after a reasonable number of attempts. 


Each transfer will be given a multicast address for use to distribute 
the data packets. Since there can be multiple servers on a given 
network or a limited number of addresses available to a given server, 
it is possible that their might be more than one transfer using a 
multicast address. To ensure that a client only accepts the correct 
packets, each transfer must use a unique port on the server. The 
source IP address and port number will identify the data packets for 
the transfer. Thus the server must send the unicast OACK packet to 
the client using the same port as will be used for sending the 
multicast data packets. 
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other than the master client, 
the server will respond with another OACK with the mc 
If this client persists in sending 
the server may send an error packet to the client, 
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discontinuing the file transfer for that client. 


The server may also send unicast packets 


sends a ACK 


to a lone client to reduce 


adverse effects on other machines. As it is possible that machines 


may be forced to process many extraneous 


multicast packets when 


message 


attempting to receive a single multicast address. 
Example 
clients server 
1 cı |1lafile|oloctet|0|multicast|o|0] -> 
2 C1 <- |6|]multicast|224.100.100.100,1758,1| 
3 cı Jaļoļ -> 
4 M <- |3ļ|1|1| 512 octets of data| 
5 cı |4|1| -> 
6 M <- |3|2|1| 512 octets of data| 
7 C2 |1lafile|O|octet|0|multicast|0]0| -> 
8 C2 <- |6|multicast]224.100.100.100,1758,0| 
9 c2 |4lo| -> 
10 cl |4]2| -> 
11 M <- |3|3|1| 512 octets of data| 
12 c3 |1lafile|Oloctet|0|multicast|0|0| -> 
13 C3 <- |6|multicast|224.100.100.100,1758,0| 
14 cl Jaļ3| -> 
15 c2 |4]o| -> 
16 M (except C2) <- |3]4|1| 512 octets of data| 
17 cı |[4|4] -> 
18 M <- |3|5|1| 512 octets of data| 
19 cı |[4|5|] -> 
20 M <- |3|6|1| 100 octets of data| 
21 cı |[4|6| -> 
22 C2 <- |6|multicast|,,1| 
23 c2 |aļoļ -> 
24 M <- |3ļ|1|1| 512 octets of data| 
25 c2 |4|1| -> 
26 M <- |3|2|1| 512 octets of data| 
27 c2 |4]3| -> 
28 M <- |[3/4|1| 512 octets of data| 
29 c2 |4|6| -> 
30 C3 <- |6|multicast|,,1| 
31 c3 |[4[2| -> 
32 M <- |3|3|1| 512 octets of data| 
33 c3 |4|6| -> 
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Comments: 
1 request from client 1 
2 option acknowledgment 
3 acknowledgment for option acknowledgment, 
or request for first block of data 
4 first data packet sent to the multicast address 
7 request from client 2 
8 option acknowledgment to client 2, 
send no acknowledgments 
9 OACK acknowledgment from client 2 
15 OACK acknowledgment from client 3 
16 client 2 fails to receive a packet 
21 client 1 acknowledges receipt of the last block, 
telling the server it is done 
23 option acknowledgment to client 2, 
now the master client 
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25 client 2 acknowledging with request for first block 
27 client 2 acknowledges with request for missed block 
29 client 2 signals it is finished 
31 client 3 is master client and asks for missing blocks 
33 client 3 signals it is finished 

Conclusion 


With the use of the multicast and blocksize[3] options TFTP will be 
capable of fast and efficient downloads of data. Using TFTP with the 
multicast option will maintain backward compatibility for both 


clients and servers. 


Security Considerations 


Security issues are not discussed in this memo. 
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